home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0399 / 182 < prev    next >
Text File  |  1994-08-27  |  5KB  |  95 lines
  1. Subject: Re: shared libraries for MiNT 
  2. Date: Tue, 30 Mar 93 13:35:38 PST
  3. From: Howard Chu <hyc@hanauma.Jpl.Nasa.Gov>
  4.  
  5.  
  6.   A Proposal for Implementing Shared Libraries
  7.   
  8.   I think I've finally figured out a "good" way to implement shared
  9.   libraries (i.e. low overhead, doesn't need VM, requires few changes
  10.   to existing applications). Here's my proposal; please let me know what
  11.   you think. (In case it isn't obvious, this is *very* far from being
  12.   cast in stone :-). I do think we need to do shared libraries soon,
  13.   though.)
  14.   
  15.   A shared library will be implemented as a DRI format object file, with
  16.   the GST long name symbol table. A program linked with shared libraries
  17.   will have the same format, but with an additional header prepended
  18.   which gives the names and version numbers of the shared libraries it
  19.   requires.
  20.  
  21. I really think we need to have an object format that includes separate
  22. segments for blockdata, blockbss, and maybe even blocktext for constant
  23. arrays & structures. That's the only way to insure enough breathing space
  24. while using 16 bit offsets.
  25.   
  26.   Both the libraries and the programs will be compiled to use
  27.   register A5 as a base register (e.g. when compiled with gcc they will
  28.   be compiled with -mbaserel). They need not be position independent;
  29.   the libraries will appear at the same virtual address (determined at
  30.   load time) in every process, and programs will be relocated at load
  31.   time by the kernel.
  32.  
  33. Just a minor note, a5 is unusable for this purpose because it is zeroed
  34. by Supexec. The current baserel stuff uses a4.
  35.   
  36.   The data and bss segments of a given shared library will always be
  37.   located at the same (relative) offset in the data/bss area of
  38.   a program using that library. (Note that I'm going to call the
  39.   "data/bss area" just the "data segment" from here on in, because the
  40.   bss is just a special part of the data segment from the kernel's point
  41.   of view.)
  42.  
  43. I don't understand how this can be enforced without collisions. Is the load
  44. address & size of the data section stored in the respective library? What
  45. happens if the library is revised and the data section changes in size? Also,
  46. it seems that trying to deal with gaps from unused libraries will be messy...
  47. Finally, what about library code referencing data symbols that are external
  48. to the library? (I think e.g. curses references some of termcap's variables...)
  49. Is this scheme going to only support Atari-generated libraries, or will anyone
  50. be able to write a shared library?
  51.   
  52.   Does this make sense? The key thing is that since everyone is using
  53.   register A5 as a base register, the libraries can always find their
  54.   data (at the particular fixed offset into the data segment assigned to
  55.   them).
  56.   
  57. It certainly has that advantage. My previous scheme involved resetting the
  58. base register on a per-library basis, but I couldn't figure out how to cope
  59. with libraries that called each other, or called back into user code (like
  60. bsearch or qsort, for example...).
  61.  
  62.   The disadvantage of this scheme is that once more than 64K of data is
  63.   filled up, libraries and/or programs that use 16 bit offsets will be
  64.   in trouble. There are ways around this, of course.
  65.   
  66.   Another disadvantage is that program load times will be longer, since
  67.   the kernel is going to have to do the relocation and symbol resolving.
  68.  
  69. Meaning that executables must never be stripped, as well, right? And, just
  70. to clarify, this is not an attempt at providing dynamic loading and linking
  71. as well, is it? (Oh, I see, you can strip any resolved symbols, of course,
  72. and only leave the unresolved ones in a program file...)
  73.   
  74.   An alternative would be to use something like Sun's global offset table.
  75.   That scheme is slower, though, since it adds another layer of indirection
  76.   to variable references.
  77.   
  78.   Please let me know your thoughts on this matter.
  79.  
  80. Perhaps if we ate up yet another address register for a per-library base
  81. register. Allow the data segment to be sized and located dynamically, with
  82. the location stored in the main program's data region, and passed into (say)
  83. a3 before entering a library routine. This pretty much requires stub routines
  84. to be linked into every program, as well as any library that calls another
  85. library. The stub will pull the correct base pointer to use from the main
  86. program's a4 base, and restore the old register before returning. The easiest
  87. way to deal with this is to assign fixed offsets from the program's base
  88. pointer for each library's private base pointer. Still can't get away from
  89. assigning some kind of fixed resource to each library, I guess.
  90.  
  91. Something else to establish that could help this discussion - is gnulib.a
  92. treated as a single library, or does it get broken up into smaller functional
  93. groups?
  94.   -- Howard
  95.